The problem of detecting deadlocks and/or race conditions in physical systems have long been difficult for system and software designers. The race condition may occur in software, hardware, or both. For example, in case of acceleration/brake problems in some automobiles equipped with software systems, it is possible that there are two different logical threads of execution for the software code embedded within the automobile: one for the brake, and one for the accelerator. FIG. 1 shows a simplified block diagram for an exemplary automobile system that takes physical inputs from accelerator and brake systems and sends those inputs to a software program for processing. As shown, the software program in the car may process each of these inputs as a separate thread.
When the software processes these threads, the threads might get into a deadlock. In other words, the brake thread ends up waiting on the accelerator thread, while the accelerator thread is waiting on the brake thread. This may result in ignoring both signals no matter which pedal is being pressed. Other examples of physical systems include control systems, industrial machineries, patient monitoring systems, and the like, which include a software system monitoring a plurality of inputs, for example, from physical stimulants or sensors.
Such race condition problems are challenging to debug because it is very difficult to reproduce the precise timing and input conditions that spurred the problem.